Since, in testing, there is never any question of unlimited time and resources, it is important to make well-founded choices as to which units (or combinations of units) of the system require more, or even less, test effort. The basis for making well-founded choices in this forms the risks of the system units and the system as a whole.

An aid in determining the risks is the execution of an elementary product risk analysis (PRA - see Product Risk Analysis). In a few cases, the PRA of the master test plan is sufficient, and in other cases, an elementary PRA is initiated from within the development testing. The way to simplify the PRA is to invite fewer participants, for example, just a few developers, a user and the test manager of the overall test process. Before the PRA can be carried out, the following points should be known:

• What is the influence of the development method and architecture employed? These influence the way in which object parts can be classified. They also bring their own risks.
• To what degree is automation used in unit and integration tests. This influences the risks.
• If the work is being carried out in accordance with the principle of basic quality and selected quality, it should be known what the agreements are in respect of this basic quality.

The risks that emerge from the PRA may influence the way in which the process of the development tests is organised. They can also influence the order in which the system will be developed. For example, in view of the risks, it may be advisable to include a Proof of Concept within the development process, in which a number of targeted development tests are explicitly executed.